本文摘要背景在给站点的「资讯频道」配一个无人值守自动发布任务（每天定时跑，选几篇信源文章、配图、发布）时，任务反复失败：日志里只有一句话——completions HTTP stream opened but did not deliver a first SSE event within 300000ms (first-event timeout)。诡异的是，同一个模型、同一个 API Key，在交互式...
背景
在给站点的「资讯频道」配一个无人值守自动发布任务（每天定时跑，选几篇信源文章、配图、发布）时，任务反复失败：日志里只有一句话——completions HTTP stream opened but did not deliver a first SSE event within 300000ms (first-event timeout)。
诡异的是，同一个模型、同一个 API Key，在交互式会话里秒回正常；唯独定时任务（cron）这条路径一跑就卡满 300 秒超时。一开始怀疑是模型服务商对定时请求路径不稳定，折腾排查了很久，最后发现根因根本不是服务商，而是模型类型选错了。
过程
问题描述
自动发布任务每次运行都在「首次模型调用」阶段卡死：
- 没有任何工具输出、没有生成任何内容
- 恰好 300000ms 后被判超时（首包超时阈值）
- 交互式会话跑同样的活，秒回
排查 / 调研
- 先排除服务端故障：直接用命令行 curl 请求同一个模型接口，单次请求秒回、返回正常。说明模型服务端本身没有挂，也不是鉴权/网络问题（流式响应头都收到了）。
- 看运行时轨迹：定时任务会话的轨迹文件里，模型调用记录显示
assistantTexts为空、idleTimedOut=true、且用量统计全是 0——也就是模型服务端压根没开始处理这个请求，请求发过去就被晾着，直到超时掐断。 - 对比交互式会话：交互式用同一个模型，首个内容 token 很快返回。
- 关键差异：定时任务配置的模型是
deepseek-v4-flash，标注为 reasoning 模型（带思考过程）；交互式会话走的是普通对话模型。把定时任务模型换成普通模型后，问题消失。
根因
reasoning 类模型在接到请求后，会先进入一段思考阶段，把推理过程跑完才会输出首个可见 token。这个思考阶段在「首包超时」看来就是"迟迟不出内容"。普通对话模型不思考、直接开吐，所以首包秒回。
在交互式场景下，这个思考时间通常可接受；但在无人值守的定时任务 + 大任务负载下，reasoning 模型的思考阶段可能非常长，直接突破 300 秒的首包超时阈值，任务还没开始干活就被判超时杀掉。
解决方案
把定时任务的模型从 reasoning 模型换成非 reasoning 的普通对话模型：
payload.model: deepseek/deepseek-v4-flash → deepseek/deepseek-chat换完后手动触发一次，全链路跑通，任务正常执行到结束。所以定时/自动化场景，优先选首包快的非 reasoning 模型。
总结
正确做法
- 无人值守的定时任务（cron），优先用非 reasoning 的普通对话模型，首包快、不容易踩首包超时。
- 遇到「交互式秒回、定时任务卡超时」时，先 curl 直测接口排除服务端和鉴权问题，不要一上来就怀疑服务商不稳定。
- 看轨迹文件里
assistantTexts是否为空、idleTimedOut是否为 true、用量统计是否全 0——"模型根本没开始处理"和"模型在处理但慢"是两种完全不同的情况，这几个字段能一眼区分。 - reasoning 模型适合对推理质量有要求的交互式场景；对"只要跑完就行、要稳"的自动化任务反而不合适。
参考
觉得内容不错？我要
